
\usepackage{listings}
\lstset{language=Java}

\usepackage{graphicx}
\usepackage{hyperref}
\hypersetup{
  colorlinks=true,
  urlcolor=blue,
  linkcolor=black
}

\mode<article>{\usepackage{fullpage}}

\title{Lecture One -- OOP Review}
\author{Matt Bone}
\date{\today}

\begin{document}

\mode<article>{\maketitle}
\tableofcontents
\mode<article>{\pagebreak}
\mode<presentation>{\frame{\titlepage}}
\mode<article>{\setlength{\parskip}{.25cm}}


\section{Object Oriented Programming}

\subsection{What is OOP?}
\begin{frame}[fragile]
  \mode<presentation>{\frametitle{What is OOP?}}
  When we say \emph{object oriented programming} what exactly are 
  we talking about?
\end{frame}

Dr. Alan Kay, a Turing Award winner, was one of the inventors of
Object Oriented Programming as we know it.  He is still an
influential computer scientist today.  Though some of the deeper
implications are beyond the scope of this course, we
will examine his quote below and use it as a starting point.


\begin{frame}[fragile]
  \mode<presentation>{\frametitle{A Quote from Alan Kay}}
  \begin{quote}
  ``OOP to me means only messaging, local retention and protection and 
  hiding of state-process, and extreme late-binding of all things. It 
  can be done in Smalltalk and in LISP. There are possibly other 
  systems in which this is possible, but I'm not aware of them.''
  \end{quote}
--Dr. Alan Kay\newline
\end{frame}

\subsection{Encapsulation}
\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Encapsulation}}

  \begin{quote}``...local retention and protection and hiding of state-process...''\end{quote}
  \begin{center}\includegraphics[height=5cm]{object}\newline\end{center}
  An object contains code and data; we manipulate the data via the code.  
  But what is the point?
\end{frame}

Well, when we properly encapsulate a variable (when we can only
manipulat the data via code), we can control where
that variable is modified and even make sure it is only modified
inside of one particular method.  By forcing these state changes to go
through one particular code path, we can easily change this path
later (a classic examples is wanting to add some sort of logging or
auditing feature).  So in its purest form encapsulation turns an
object into a black box whose implementation details are hidden from
the outside world and whose functionality is exposed only through
methods of the designer's choosing.

Again, with proper encapsulation we only modify state through method
calls as we see below.  Dr. Kay calls this:  

\begin{frame}[fragile]
  \mode<presentation>{\frametitle{How do we modify state? Messaging vs. Methods}}
  \begin{quote}``...messaging...''\end{quote}
  Smalltalk: send the message \verb'add' with a value of five to the \verb'myBigInt' object:
  \begin{verbatim}
    myBigInt add: 5 
  \end{verbatim}
  Java: invoke the \verb'add' method on the \verb'myBigInt' object with an argument of five:
  \begin{verbatim}
    myBigInt.add(5);
  \end{verbatim}
\end{frame}

For historical reasons, read up on the Smalltalk programming language,
we can consider `messaging' to be analagous to `calling methods.'
Language purists may disagree, and indeed Dr. Kay regrets not calling
OOP ``message oriented programming'' but this debate is left for
another time.

Another reason given for object orientation is code reuse.  It is best
to be careful here however; code reuse is best accomplished by
conscientious design.  Creating a new class does not automatically
make your code reusuable, and, indeed, we can write reusuable code
with any programming paradaigm.

\subsection{Visibility Modifiers}
We use the visibility modifiers below to enforce encapsulation.  Not
all object oriented languages offer the ability to enforce
capsulation; some rely on the programmer to adhere to encapsulation by
convention.  

\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Visibility Modifiers}}
  
  \begin{tabular}{|l|l|}
  \textbf{Modifier}&\textbf{Visibility}\\
  \verb'private'&only instances of this class\\
  \verb'protected'&instances of this class and subclasses\\
  \verb'package' (default, no modifier)&instances of this class, subclasses, other package classes\\
  \end{tabular}\\

  These modifiers can apply to classes, methods, or instance variables.
\end{frame}

\subsection{Objects and Classes in Java}
An object \emph{is an instance of} a class, and we use the
\verb'new' operator to \emph{instantiate} that class:
\begin{verbatim}
MyNewClass a;
a = new MyNewClass();
\end{verbatim}

There can be many instances of a class.  Data is not usually shared
between instances.  As an example consider the \verb'BigInteger' class
which is used to represent integers that are too large to fit in a
regular \verb'int'.  Though we may have
\verb'b=new BigInteger(45)' and \verb'c=new BigInteger(42)', \verb'b' 
and \verb'c'are instances of the same class, share the same properties
and methods, but do not share the same data.

\subsubsection{Defining Equality or Overriding .equals()}
The \verb'.equals()' method compares two objects logically and is
defined in the \verb'Object' class.  We can and usually should define
what \emph{logically equivalent} means for each by class basis by
simply overriding the \verb'.equals()' method.

\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Defining Equality or Overriding .equals()}}
  \begin{lstlisting}
  public class EgalitarianObject {
    public boolean equals(Object obj) {
      return true;
    }
  }
  \end{lstlisting}
\end{frame}


\subsubsection{Less Than What? or Overriding .compareTo()}
\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Less Than What? or Overriding .compareTo()}}
  The \verb'compareTo' method returns an integer that represents
  the relationship between two objects.\newline

  \begin{tabular}{|l|l|}
  \verb'a.compareTo(b)'&\textbf{meaning}\\
  \verb'< 0'&object \verb'a' \emph{less than} \verb'b'\\
  \verb'= 0'&object \verb'a' \emph{is equal to} \verb'b'\\
  \verb'> 0'&object \verb'a' \emph{greater than} \verb'b'\\
  \end{tabular}\newline

  Note that this method is not built into \verb'Object', and objects
  wanting to use it should implement the  \verb'Comparable' interface
\end{frame}

\subsubsection{Making a Name for Ourself or Overriding .toString()}
\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Making a Name for Ourself or Overriding .toString()}}
  Every object has a string representation that can be requested
  with the \verb'toString()' method.
  \begin{lstlisting}
  public class Employee {
    ...
    public String toString() {
      return this.firstName + `` '' this.lastName;
    }
  }
  \end{lstlisting}
\end{frame}

\section{OOP in a Statically Typed Language}

\subsection{Polymorphism}
\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Polymorphism}}
  \begin{quote}``...extreme late binding...''\end{quote}

  \begin{itemize}
  \item \textbf{poly} - many  
  \item \textbf{morph} - shapes
  \end{itemize}
\end{frame}

Types in Java and many other object oriented languages can exhibit the
properties of other types.  That is, the can be characterized by many
forms; they are polymorphic.

\subsection{Inheritance and the class hierarchy}
\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Inheritance and the class hierarchy}}
  \begin{center}\includegraphics[height=5cm]{diagram1}\newline\end{center}

  Kay does not mention inheritance by name, but others claim it is an
  integral part of OOP.

\end{frame}

In Java, classes can have any number of subclasses and must have one
and only one parent class.  If there is no parent class explictly
declared with the \verb'extends' keyword in the class signature then
the \verb'Object' class is the parent class. Inside class
implementations, the parent or super class may be referred to with the
\verb'super' keyword (only accessible methods and variables may be
accessed, i.e. not private methods or private variables).

\subsection{Programming to an Interface}

\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Programming to an Interface}}
  A Java interface specifies methods without implementations.  Classes
  implementing such an interface are required to implement all of
  its methods.

  \includegraphics[height=4cm]{interfaces}\newline
\end{frame}

Throughout the first chapter the author makes somewhat of an arbitrary
distinction between the `user' of a class and the `developer' of a
class.  Though some of his points are certainly valid, this
distinction falls short when describing the importance of interfaces.
Interfaces are about polymorphism.

In practice interfaces are important because they specify a commonality
that is shared across all implementations.  Say we wanted to write a
program that loaded a file, but we wanted to be able to load files
from the local filesystem as well as a network filesystem.  One
approach would be to write two completely seperate classes, but this
could become cumbersome.  A better approached would be to write a
\verb'FileLoader' interface and then write two classes that implement this
interface.  Thus any code that only used the methods specified in the
interface could load both networked and local files without changing
anything.


\section{OOP and Memory}

\subsection{Object References}
\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Object References}}

  \begin{lstlisting}
   BigInteger b1;
  \end{lstlisting}

  \verb'b1' is not an object.  It is an \textbf{object reference}.  
  At the moment this reference is unititialized.    

  \pause
  \begin{lstlisting}
  b1 = new BigInteger("42");
  \end{lstlisting}

  Now we have created a new object in memory, a \verb'BigInteger' that 
  represents the number 42.  \verb'b1' now points to this object. 

\end{frame}

Now as an aside, remember garbage collection:
\begin{lstlisting}
  b1 = null;
\end{lstlisting}

Now \verb'b1' points to nothing and there are no more references to the our 
\verb'BigInteger' of 42


Java and many other programming languages have two ideas about
whether or not objects are the same.
\subsection{Identity vs. Equality}

\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Identity}}
  \textbf{Identity}: Two references point to the same object in memory.
  
  \begin{center}\includegraphics{identity}\end{center}
\end{frame}

\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Equality}}
  \textbf{Equality}: Two objects are logically equivalent 
  \begin{center}\includegraphics{equality}\end{center}
\end{frame}

\subsection{Pass by value vs. pass by reference}
Going along with identity and equality, we have the issue of pass by
reference and pass by equality.  This has to do with how values are
passed into a method.
\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Pass by value}}
  \begin{lstlisting}
  public void method1() {
    int a = 5;
    method2(a);
  }
  
  public void method2(int a) {
    a += 5;
  }
  \end{lstlisting}
Even after calling \verb'method2' inside of \verb'method1', \verb'a' 
still has the value of 5 because \verb'a' is passed by value.  
That is, it is copied.
\end{frame}


\begin{frame}[fragile]
  \mode<presentation>{\frametitle{Pass by reference}}
  \begin{lstlisting}
  public void method3() {
    BigInteger a = new BigInteger("5");
    method4(a);
  }

  public void method4(BigInteger a) {
    a.add(new BigInteger("5"));
  }
  \end{lstlisting}
Now after calling \verb'method4', \verb'a' will have a value of 10.  This is 
because it is passed by reference.  That is, it is copied.
\end{frame}

\begin{frame}[fragile]
  \mode<presentation>{\frametitle{References are passed by value}}
  \begin{lstlisting}
  public void method5() {
    BigInteger a = new BigInteger("5");
    method6(a);
  }

  public void method6(BigInteger a) {
    a = new BigInteger("42");
  }
  \end{lstlisting}
Now after calling \verb'method6', \verb'a' will still be 5.  The object reference 
(in this case \verb'a') is itself passed by value.
\end{frame}

\end{document}
